Use Case Reference – 用例模板, 场景书写准则

Categories: Development Notes; Tagged with: Better Developer • Use Case • 用例; @ January 8th, 2009 23:50

用例Use cases:

User Case 用例	增加学生
Brief description	增加/修改学生
Scope/Level	AthenaES/User goal	Primary actor/role	管理员
Minimal & Success Guarantees 保证	Minimal: The system logs how far it may get Success: 新的学生被添加; 被更新(E3)
Preconditions 前提	Actor is logged in
Triggers 引发条件	用户点击”ADD”
Main Success Scenario 成功场景	1. 用户点击”ADD” 2. 系统打开编辑用户界面 3. 用户输入符合要求的: 姓名年龄性别[可选] 4. 用户点击”Save” 5. 系统保存学生成功, 系统关闭编辑窗口并返回主窗口
Extension 扩展 #1	4a: 用户点击”Cancel”, 系统关闭编辑窗口并返回主窗口
Extension 扩展 #2	5a: 系统无法连接服务器或服务器存储报错, 提示错误
Extension 扩展 #3	编辑学生: 1b: 用户选中学生之后点击”Edit” 5b: 系统保存学生成功, 系统关闭编辑界面并返回主界面
Notes and Issues	无

场景书写准则

场景书写准则

举例

使用简洁明确的句子

格式: 主语 + 谓语动词 + 直接宾语 + 状语
√ 用户点击”ADD”按钮

从系统外部以第三人称视角来编写用例

× 读取ATM卡和PIN号码, 并从帐号余额中扣除一定数量
√ 用户插入ATM卡并输入PIN; 系统从帐号余额中扣除一定数量

记录执行者的意图, 而非具体动作

× 1) 系统要求用户输入姓名 2) 用户输入姓名 3) 系统要求输入年龄 4) 用户输入年龄	√ 1) 用户输入姓名和年龄或: 1) 用户输入 – 姓名 – 年龄
× 1) 用户按下Tab键	√ 2) 用户输入地址

包含”合理”的活动集

3到6步是较为合适 & 具体情况具体分析 – 可以把每个部分作为一个单独的步骤, 也可以用不同的方式合并其中的几个部分, 甚至可以合并为一个步骤, 具体要视每个部分的复杂程度和执行过程中什么地方会发生自然中断来决定的. 一般来说的.

“确认” 而不是 “检查是否”

×
1) 系统检查密码是否正确
2) 如果密码正确, 系统向用户提供有效的操作

√
1) 系统确认密码正确
2) 系统向用户提供有效的操作

必要时的时间限制

√ 在步骤3跟步骤5之间的任何时候, 用户将…
√ 当用户…系统将…

习惯用语: “用户让系统A与系统B交互”

×
1) 用户通知系统从系统B获取数据
2) 系统从系统B获取后台数据

√
1) 用户命令系统从系统B获取数据

习惯用语: “循环执行步骤x到y, 直到条件满足”

√
1) 顾客提供帐号或者姓名和地址; 2) 系统查出顾客的爱好信息
3) 用户选择一个商品, 并做上购买的标记; 4) 系统将这个商品加入顾客的”购物车”中
顾客重复步骤3~4 , 直到顾客指明他已完成购物
5) 顾客购买所有在购物车中的商品

参考书目: Writing Effective Use Cases